InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/misc/merit/noop/plans/nearnet

Text File | 1992-03-05 | 14KB | 279 lines

On Wednesday, February 26th, the NEARnet Steering Committee accepted the
recommendation of the technical subcommittee by adopting the following policy
for the routing of CLNS traffic within NEARnet.  It is hoped that this plan
will assist OSI interoperability testing between developers and lead to more
mature OSI products in the future.

Please direct any questions or comments to "[e-mail]".

John Curran
NEARnet Staff
---

            NEARnet OSI Routing Plan


This is an informational document specifying guidelines for the implementation
of Open Systems Interconnection (OSI) connectionless network protocol (CLNP)
networking within NEARnet.  The document describes a plan for coordinating OSI
addressing, assigning routing domains to NEARnet members, establishing CLNP
routing within NEARnet, and coordinating CLNP routing with external networks.
This document does not specify that NEARnet will offer CLNS transport service;
requests for CLNS non-production trials will be accepted from members with
existing expertise (as demonstrated by a history of the support of CLNS on
their own internal networks.)

This document is intended for NEARnet members but may be useful to other
members of the Internet community.  Much of the material herein is based upon
the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda
Winkler (ANL) and NEARnet is grateful for their assistance.  It is hoped that
documents such as these will help encourage the growth of OSI services within
the Internet.


NEARnet OSI Addressing
======================

In OSI, each system is associated with a Network Service Access Point (NSAP)
address.  NSAP's are analogous to Internet Protocol (IP) addresses in that each
system must be assigned a unique address in order to successfully communicate.
In IP, the addresses that a given system may be assigned is constrained by the
IP network number it is attached to.  This allows for abstraction of routing
information by other networks.  NSAP's are structured in a similar manner which
allows abstraction of routing information to occur at many different levels in
the network.

The document that defines the semantics of an NSAP is ISO 8348/Addendum 2.
The basic components of the NSAP is the initial domain part (IDP) and the
domain specific part (DSP).  The initial domain part identifies the authority
that is responsible for both the structure and the uniqueness of the address.
In NEARnet, the vast majority of the NSAP's encountered will be within the same
initial domain part: 47.0005.  This is the portion of the NSAP address space
which is assigned to the U.S. Government.  This IDP is administered by the
General Services Administration (GSA) for the National Institute of Standards
and Technology (NIST). U.S. organizations may apply to GSA for their own unique
prefix for the domain specific portion of this address space, and such prefixes
are known as administrative authority identifiers.

NEARnet has been assigned an Administrative Authority (AA) value by the GSA.
This AA value identifies a set of NSAP addresses which may be allocated to
NEARnet members as needed.  The AA assigned to NEARnet is FFFE00 (16) and the
addresses follow the GOSIP V2 NSAP format:

     47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL

where    rsvd is two reserved octets of zero
    RD is a two octet routing domain
    Area is a two octet area within the RD
    ID is a six octet system identifier
    and SEL is a one octet nsap selector.

The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out
of the NEARnet AA.  Each NEARnet member will be assigned one or more RDs from
the NEARnet AA. Each member will have the authority to assign Area Identifiers
(2 bytes) within its RD to best serve its topology and its users.  NEARnet
backbone routers will carry only information about members' routing domains,
and will not carry information about member area assignments. As a result,
each member's local addressing and topology will be transparent to the NEARnet
backbone routers.  Sites with connections to networks in different AAs, or
whose primary path is a network other than NEARnet may want to obtain an RD
>From that network's administrative authority.

For NEARnet members who are assigned an AA by another authority, the NEARnet
backbone routers will carry the minimum amount of information needed to route
to that member. In some cases it may be necessary for members to acquire their
own Administrative Authority assignment if they desire multiple network
connections to provide automatic failover between providers.


NEARnet CLNP Routing
====================

Any NEARnet member which participates in CLNS transport will provide an NSAP
address for the NEARnet router on their network.  The NEARnet router will use
Cisco's IGRP to exchange CLNP routing information with a site if the site is
using a Cisco router.  If it is not, static CLNP routing will be used until
the ISO Interdomain Routing Protocol (IDRP) is widely available from router
vendors.

Routing between AAs will occur where NEARnet peers with other network service
providers. Such routing exchanges will involve the minimum information needed
to represent the networks served.  In the initial case, NEARnet will provide
other network providers with a route to NEARnet's AA prefix which will be
sufficient to route to all NEARnet provided routing domains. Additional routes
would be exchanged as NEARnet members acquire their own AA assignments. Again,
IGRP or static routing will be used to facilitate these routing exchanges
until IDRP is readily available.

Routing within NEARnet will use IGRP.  Each NEARnet router will be assigned
as NSAP from a single NEARnet backbone routing domain.  Member routing domains
will be assigned based upon the hub or branch node connected into, which will
allow for route aggregation at each hub.  This aggregation will reduce the
routing workload on the individual routers, and will also allow for future
network topologies based upon state or LATA boundaries.  It is expected that
members may move from branch node to branch node in the future; the goal of
allocating routing domains is simply an optimization which allows for route
compression for the normal case.

NEARnet Routing Domain Requests
===============================

Members who require a routing domain assignment for participation in
OSI networking should fill out a Routing Domain Assignment request
(available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt)
and mail the completed request to "[e-mail]".


From [e-mail] Fri Feb 28 14:23:14 1992
Received: from nic.near.net by merit.edu (5.65/1123-1.0)
    id AA21419; Fri, 28 Feb 92 14:14:23 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: NEARnet OSI Routing Plan
Date: Fri, 28 Feb 92 14:14:21 -0500
From: John Curran <[e-mail]>
Status: RO

FYI.
/John

------- Forwarded Message

Received: from nic.near.net by nic.near.net id aa18311; 28 Feb 92 13:12 EST
To: [e-mail]
cc: [e-mail]
Reply-to: [e-mail]
Subject: NEARnet OSI Routing Plan
Date: Fri, 28 Feb 92 14:11:26 -0500
From: John Curran <[e-mail]>

On Wednesday, February 26th, the NEARnet Steering Committee accepted the
recommendation of the technical subcommittee by adopting the following policy
for the routing of CLNS traffic within NEARnet.  It is hoped that this plan
will assist OSI interoperability testing between developers and lead to more
mature OSI products in the future.

Please direct any questions or comments to "[e-mail]".

John Curran
NEARnet Staff
- ---

            NEARnet OSI Routing Plan


This is an informational document specifying guidelines for the implementation
of Open Systems Interconnection (OSI) connectionless network protocol (CLNP)
networking within NEARnet.  The document describes a plan for coordinating OSI
addressing, assigning routing domains to NEARnet members, establishing CLNP
routing within NEARnet, and coordinating CLNP routing with external networks.
This document does not specify that NEARnet will offer CLNS transport service;
requests for CLNS non-production trials will be accepted from members with
existing expertise (as demonstrated by a history of the support of CLNS on
their own internal networks.)

This document is intended for NEARnet members but may be useful to other
members of the Internet community.  Much of the material herein is based upon
the "CICNET OSI ROUTING ARCHITECTURE" by Tom Easterday (CICNet) and Linda
Winkler (ANL) and NEARnet is grateful for their assistance.  It is hoped that
documents such as these will help encourage the growth of OSI services within
the Internet.


NEARnet OSI Addressing
======================

In OSI, each system is associated with a Network Service Access Point (NSAP)
address.  NSAP's are analogous to Internet Protocol (IP) addresses in that each
system must be assigned a unique address in order to successfully communicate.
In IP, the addresses that a given system may be assigned is constrained by the
IP network number it is attached to.  This allows for abstraction of routing
information by other networks.  NSAP's are structured in a similar manner which
allows abstraction of routing information to occur at many different levels in
the network.

The document that defines the semantics of an NSAP is ISO 8348/Addendum 2.
The basic components of the NSAP is the initial domain part (IDP) and the
domain specific part (DSP).  The initial domain part identifies the authority
that is responsible for both the structure and the uniqueness of the address.
In NEARnet, the vast majority of the NSAP's encountered will be within the same
initial domain part: 47.0005.  This is the portion of the NSAP address space
which is assigned to the U.S. Government.  This IDP is administered by the
General Services Administration (GSA) for the National Institute of Standards
and Technology (NIST). U.S. organizations may apply to GSA for their own unique
prefix for the domain specific portion of this address space, and such prefixes
are known as administrative authority identifiers.

NEARnet has been assigned an Administrative Authority (AA) value by the GSA.
This AA value identifies a set of NSAP addresses which may be allocated to
NEARnet members as needed.  The AA assigned to NEARnet is FFFE00 (16) and the
addresses follow the GOSIP V2 NSAP format:

     47.0005.80.FFFE00.rsvd.RD.Area.ID.SEL

where    rsvd is two reserved octets of zero
    RD is a two octet routing domain
    Area is a two octet area within the RD
    ID is a six octet system identifier
    and SEL is a one octet nsap selector.

The NEARnet backbone will be assigned one Routing Domain Identifier (RD) out
of the NEARnet AA.  Each NEARnet member will be assigned one or more RDs from
the NEARnet AA. Each member will have the authority to assign Area Identifiers
(2 bytes) within its RD to best serve its topology and its users.  NEARnet
backbone routers will carry only information about members' routing domains,
and will not carry information about member area assignments. As a result,
each member's local addressing and topology will be transparent to the NEARnet
backbone routers.  Sites with connections to networks in different AAs, or
whose primary path is a network other than NEARnet may want to obtain an RD
from that network's administrative authority.

For NEARnet members who are assigned an AA by another authority, the NEARnet
backbone routers will carry the minimum amount of information needed to route
to that member. In some cases it may be necessary for members to acquire their
own Administrative Authority assignment if they desire multiple network
connections to provide automatic failover between providers.


NEARnet CLNP Routing
====================

Any NEARnet member which participates in CLNS transport will provide an NSAP
address for the NEARnet router on their network.  The NEARnet router will use
Cisco's IGRP to exchange CLNP routing information with a site if the site is
using a Cisco router.  If it is not, static CLNP routing will be used until
the ISO Interdomain Routing Protocol (IDRP) is widely available from router
vendors.

Routing between AAs will occur where NEARnet peers with other network service
providers. Such routing exchanges will involve the minimum information needed
to represent the networks served.  In the initial case, NEARnet will provide
other network providers with a route to NEARnet's AA prefix which will be
sufficient to route to all NEARnet provided routing domains. Additional routes
would be exchanged as NEARnet members acquire their own AA assignments. Again,
IGRP or static routing will be used to facilitate these routing exchanges
until IDRP is readily available.

Routing within NEARnet will use IGRP.  Each NEARnet router will be assigned
as NSAP from a single NEARnet backbone routing domain.  Member routing domains
will be assigned based upon the hub or branch node connected into, which will
allow for route aggregation at each hub.  This aggregation will reduce the
routing workload on the individual routers, and will also allow for future
network topologies based upon state or LATA boundaries.  It is expected that
members may move from branch node to branch node in the future; the goal of
allocating routing domains is simply an optimization which allows for route
compression for the normal case.

NEARnet Routing Domain Requests
===============================

Members who require a routing domain assignment for participation in
OSI networking should fill out a Routing Domain Assignment request
(available via ftp from nic.near.net:/docs/osi-routing-domain-request.txt)
and mail the completed request to "[e-mail]".

------- End of Forwarded Message